As shown in FIG. 1, the JTAG (Joint Test Action Group) Architecture involves providing an integrated circuit 2 with a boundary-scan cell 4 coupled between each terminal pin 6 and on-chip system logic 8, whereby signals at the boundary of the IC can be controlled and observed using scan testing principles. The cells 4 effectively provide individual stages of a shift register (as shown in FIG. 3), and other integrated circuits connected to the same board (not shown) are likewise coupled to form a very long shift register composed of the individual boundary cells. A boundary cell normally provides a sample capability of input data from the terminal pin, a sample capability of output data from the system logic, a set capability of the output data, and a transparent mode.
The JTAG Architecture is shown in FIG. 2 for implementation on the chip 2 of FIG. 1. The various pads indicated comprise the terminal pins 4 of FIG. 1 and receive the signals indicated TCK, TMS, TRSTB, TDI, and providing an output signal TDO. TAP controller logic 20 is provided which provides the gated clock signals and control signals indicated in FIG. 2 to an instruction register 22, whence instructions in the register are decoded by an instruction D code unit 24 to provide appropriate control signals to a group of registers 26 known as test data registers and comprising a boundary-scan register, a device identification register, a design specific test data register and a bypass register. The output of these registers are coupled via multiplexers 28 and a D type flip-flop 29 to provide output signal TDO.
The JTAG Architecture provides standardized approaches to: (1) testing the interconnection between IC's once they have been assembled onto a printed circuit board, (2) testing the IC itself, and (3) observing or modifying circuit operation during a component's normal operation.
A known implementation of a boundary-scan cell with sample, preload and set capability is shown in FIG. 3 as comprising a data in port DI coupled to a first input of a multiplexer 30 and a first input of a multiplexer 32. The output from multiplexer 32 provides a signal out port DO. A second input of multiplexer 30 is coupled to receive a scan in signal TDI. Multiplexer 30 has a select input coupled to receive a shift/load signal SHDR. The output of multiplexer 30 is coupled to the D input of D-type capture flip-flop 24 whose output is coupled to the D input of an D type update flip-flop 36, whose output is coupled to a second input of multiplexer 32. The output of flip-flop 34 also provides a scan out signal TDO. Multiplexer 32 has a select input coupled to receive a mode signal. Flip-flops 34 and 36 are coupled to receive gated clock signals CKDR, UDDR respectively. The various control signals and gated clock signals are generated by tap controller 20 of FIG. 2.
The implementation shown in FIG. 3 is asynchronous in the sense that the clock signals CKDR, UDDR, are clock signals produced by gating an input clock signal TCK within tap controller 20 of FIG. 2. Such gated clock signals produce problems of racing in a complex design and in practice it will not be possible to check out all race related hazards with a logic simulator. Tracing the source of such hazards (glitches, spikes) and correcting them can be extremely time consuming and expensive.
Further such problems arising from asynchronism imply that CAD tools, in particular ATPG (automatic test pattern generation) software diagnostic tools, cannot be efficiently used, since they require a synchronous environment.